1. Field of the Invention
This invention relates generally to shared computing services, and more particularly to systems and methods for developing, providing, managing, and consuming virtual services through a service governance framework.
2. Description of the Related Art
Today, web services are the preferred standards-based way to realize Service Oriented Architecture (SOA). A web service is typically composed of a number of related operations. Each operation is designed for a different purpose and serves a different kind of request, such as creating or deleting a customer. An operation is typically a single unit of functionality that processes a particular kind of request from a service consumer. The requirements for and usage of the same service can change from consumer to consumer depending on the consumer's role, on the consumer's usage scenario, or on security issues, making it difficult, if not impossible, for consumers to use the service “as is.” Therefore, in typical systems, a separate web service is created for each group of users based on their requirements. This complicates the implementation of the services and contradicts a key principle of SOA, service reuse. Furthermore, as the number of consumers and service consumption scenarios in an organization grows, so does the need for separate services. This can make an SOA ecosystem very complex and difficult to manage.
In addition, in many cases organizations have to rely on services exposed out of packaged, legacy, and/or external systems that are known to expose service interfaces with a variety of imperfections, such as:                Missing operations that are required by the consumers        Exposure of irrelevant, implementation-specific or “back-door” operations that should not be exposed to outside parties        Scattering of logically related operations across a number of disparate services        Providing inappropriate, misleading, or irrelevant names for services and/or operations        
In early SOA platforms, there was an assumption that a developer of new functionality (e.g. a business application) maintains control over all of the important parts of the application. However, this is no longer always true. In the past, the developers maintained control over the producers and consumers of specific capabilities either by defining them directly or by virtue of making choices to use (or not to use) certain versions of certain third-party libraries as part of their solutions. Once these choices were made and their suitability was verified, the developer could rely on everything remaining the same at least until the next development cycle. This may also no longer be the case for post-pilot SOA implementations. Instead, different components of composite applications may exist in different organizations, business units, and countries. In some cases, services are exposed from black box implementations. In addition, both service producers and consumers might undergo changes independently of each other, evolving, moving, merging, splitting and even disappearing completely. To overcome some of these issues, various service virtualization techniques have been developed.
In general, service virtualization represents decoupling of the service interface presented to consumers of the service from the actual interface exposed by the service implementation. There are different forms of virtualization, each of which allows some level of reuse of existing services and each of which may also be used in conjunction with governance solutions. Existing governance solutions, e.g., gateway-based governance solutions, typically take a very narrow view of service virtualization, and are usually limited to endpoint and/or binding level virtualization. For example, such gateways typically sit between the service implementation of a governed service and the service consumers, and force the latter to redirect their requests to the virtual endpoints exposed by the gateway instead. The gateways listen on those virtual endpoints, validate, monitor, and enforce governance policies on the service requests (from service consumers) and on the responses (from the service implementation). This is generally referred to as endpoint virtualization.